@benjyw: How should I update the Rust option parser for this new option type? I see the following warning:

22:51:16.73 [WARN] Found differences between the new native options parser and the legacy options parser in scope [GLOBAL]:

- Failed to parse options with native parser due to error:
    The duration value `0:00:03` must be in `NUMBER UNIT` format.

TBH I think the options system types are already too complicated. As an alternative, maybe all durations could be integers representing milliseconds (do we ever actually need microseconds)? Or floats representing seconds? Or just strings with the interpretation done entirely on the consuming side in Python in some helper?

If you want to go down this path then the Rust side type should be String, with the interpretation done in Python (similar to what we do for addresses and so on).

TBH I think the options system types are already too complicated. As an alternative, maybe all durations could be integers representing milliseconds (do we ever actually need microseconds)? Or floats representing seconds? Or just strings with the interpretation done entirely on the consuming side in Python in some helper?

If you want to go down this path then the Rust side type should be String, with the interpretation done in Python (similar to what we do for addresses and so on).

You elude to my ulterior motive here: Uniform treatment from the user's perspective of all duration-typed options. We have some options which are seconds and some which are millis. Converting to timedelta on Python side is nice; but consistent user experience is my goal.

Do you consider allowing users to provide a duration string to be too much complication? As it is, users have to figure out what unit the option is using to use the options correctly. Allowing them to just specify what they want could be seen as less complicated. Thoughts?

What is the migration plan for existing options here - how would you interpret a naked integer? Fail on it after a deprecation period?

In any case, if you want to do this, I would not add a type for this in Rust, but have it be a String, and then interpret that string somewhere. Which is what we already do for all sorts of types like Address that are not explicitly handled in Rust.

What is the migration plan for existing options here - how would you interpret a naked integer? Fail on it after a deprecation period?

Migration thoughts:

1. The default unit would be seconds since N would be interpreted the same as N.0 since floating point would also be accepted to specify fractional seconds. If we want the unit always specified, we could as you mention eventually introduce that as a requirement but need not do that.
2. Existing options with "millis" or units in the name would be renamed (with appropriate deprecation cycle) to not have the unit in the option name.